LISTSERV’s security options are wide ranging, from almost no protection (easiest to administer a list, but also most open to hacker attacks) to total protection requiring validation of each and every command sent to LISTSERV for the list. It is also possible to limit access to various aspects of the list, such as who can subscribe, who can review the list of subscribers, and who can access the list archives. The list can be hidden from the LIST command, either at the global level or from all requests, including those from users on LISTSERV’s local machine, or from a definable range in between.
Note: LISTSERV does not set any file system permissions for any files. LISTSERV's security features are meant to allow and deny access to LISTSERV's various files depending on how various keywords are set, but in order to make your system completely safe, you must ensure that you have also set file and directory permissions appropriately for your operating system. For instance, LISTSERV may deny GET access to certain list archive files to non-subscribers, but if you have not set the appropriate file system permissions at the operating system level, you may have left open a window for someone to reach these files via anonymous ftp.
The VALIDATE= keyword controls the level of command validation desired for the list. The default,
VALIDATE= NO, requires password validation only for storing the list on the server. This is often sufficient for general needs. However, when a list is set this way, LISTSERV only compares the RFC822 "Sender:"/"From:" headers against the Owner= keyword(s) in the list header to determine whether or not the person ostensibly sending the commands has authority to do so. Otherwise at this level LISTSERV does not validate commands it receives for the list, under the assumption that the mail it receives is genuinely coming from a list owner. This level of validation does not protect the list from commands issued by hackers who have forged mail in the name of the list owner. If you run a list on a controversial topic or just don't feel comfortable without at least some security,
VALIDATE= NO is probably not for you.
The next level is VALIDATE= YES. At this level, LISTSERV requires a password for all of its "protected" commands. This password is the sender’s personal LISTSERV password as defined by the
PW ADD command. The commands protected by this level are those that affect subscriptions or the operation of the list, for example,
DELETE or
ADD. Users will also have to validate most commands that affect their subscriptions, but generally can do so using the "OK" mechanism rather than defining a personal password. Note that some user commands will be forwarded to the list owner for validation rather than accepting password validation from the user.
The next level is VALIDATE= YES,CONFIRM. At this level, LISTSERV will require validation with the "OK" mechanism (see below) by default, but will still accept passwords where appropriate. While the less-secure passwords are still accepted, this is considered a good compromise between list security and list owner and user convenience.
The next level is VALIDATE= YES,CONFIRM,NOPW. At this level, LISTSERV will no longer accept passwords as validation for protected commands. The logic is that because of the way the "OK" mechanism is implemented, passwords are not as safe as "magic cookies". This is the recommended setting for lists that must be kept secure.
Two other levels are VALIDATE= ALL,CONFIRM and
VALIDATE= ALL,CONFIRM,NOPW. These levels require "OK" validation for all commands that cause a change in state except for the
PUT command. If
NOPW is not specified, passwords are accepted where appropriate. With these levels, commands that do not cause a change in state (e.g.,
QUERY and other strictly-informational commands) do not require validation.
Note: LISTSERV requests coming from the local system via CP MSG or CP SMSG on VM systems or via LCMD on VMS or Unix systems never require validation, as they cannot be forged.
Lists which are set to either Validate= Yes,Confirm,NoPW or
Validate= All,Confirm,NoPW may not be managed via the web administration interface, which is password-driven.
See the List Keyword Reference document
for complete information on the
VALIDATE= keyword.
Subscription requests are controlled by use of the SUBSCRIPTION= keyword. By default, this keyword is set to
SUBSCRIPTION= BY_OWNER, meaning that all subscription requests will be forwarded to the list owner for disposition. Subscription requests can be refused completely by setting
SUBSCRIPTION= CLOSED.
To code a list for open subscriptions without list owner intervention, set SUBSCRIPTION= OPEN. If it is desired to add protection against forged subscription requests or bad return mailing paths, code
SUBSCRIPTION= OPEN,CONFIRM. The latter will cause a subscription confirmation request to be sent to the prospective subscriber, which he or she must respond to using the "OK" confirmation mechanism.
It may be desirable to restrict access to a list to people in a small area. For instance, you probably would not want a list for students in a class section at a university to be advertised or accessible by people all over the world. However, without setting certain keywords appropriately, such a list will be visible to a
LISTS GLOBAL command.
The local list of (public) lists can be retrieved only by those users who are considered local, per the setting of the server-wide
LOCAL= variable in LISTSERV's site configuration file. All other users will be told that none of the lists on the server are visible via the LISTS command, and will be referred to the use of the
LISTS GLOBAL search-text command or to the CataList. This is regardless of the setting of
Confidential= as outlined below.
To simply hide a list from a LISTS command, but still allow people to subscribe to it if they know it is there, use the keyword
Confidential= YES. Note that users subscribed to the list as well as the list owner(s) will be able to see the list if they issue a
LISTS command. In addition, all other non-subscribers, including users on the local machine, will not be able to determine that the list exists via a
LISTS command.
Service= can also be set to
Service= LOCAL, meaning it will use either LISTSERV’s global definition of which machines are
LOCAL, or the machines defined by the list keyword
Local=. The LISTSERV maintainer should define hosts and nodes that are considered local with the server-wide
LOCAL= variable in the site configuration file. If the global definition is not suitable, it can be overriden by defining the
Local= list header keyword:
If there are many subdomains within your primary domain, it may be preferable to use the wildcard when defining the
LOCAL or
SERVICE list header keywords. For instance:
Note: Defining a service area for a list controls only from which domains subscription requests may be accepted. It does not control who may post to the list. Depending on local circumstances, it may be desirable to set lists with controlled service areas to Confidential= Service.
For whatever reason, it may be desirable to restrict the ability to review the subscriber list either to subscribers or to list owners. This is done by setting the
REVIEW= keyword appropriately.
Reviews can also be restricted to users within the list’s service area by setting REVIEW= SERVICE, and defining the
SERVICE= keyword appropriately (see the preceding section).
Note: Unless the list is set to "
Confidential= Yes" or "
Confidential= Service", a request to
REVIEW a list by someone who is not allowed to do so will result in the header of the list being sent to the user along with a note to the effect that the
REVIEW command is restricted for this list. See Section 23.9
Hiding Selected Header Lines regarding hiding header lines if you want to hide parts of the header but do not want to use the "
Confidential=" keyword.
Restricting access to the list’s notebook archive files is similar to controlling who may review the list. It is accomplished by setting the fourth parameter of the
NOTEBOOK= keyword to an appropriate value. For instance,
defines a monthly notebook on LISTSERV’s A disk that is accessible by anyone. Change Public to Private if you wish only subscribers to be able to access the notebooks. The same access-levels are available for this keyword as for
REVIEW=. (See the
List Keyword Reference document for a discussion of access-levels.)
It is possible to define "Service=" in terms of IP address blocks in order to limit access to list archive notebooks. See "
Service=" in the
List Keyword Reference document for details.
The Send= list header keyword is the basic control for who may post mail to the list. If the list allows non-subscribers to post, set
Send= Public. (This is the default.)
|
•
|
Send= Editor forwards all postings to the list editor (see the Editor= and Moderator= keywords). This setting allows the editor to make changes before forwarding the message back to the list. Note that your mail program must be capable of inserting "Resent-" header lines in your forwarded mail—if it is not capable of this, all such posts forwarded to the list will appear to be coming from the editor. Check with your system administrator if you are not sure whether or not your mail program inserts the "Resent-" headers.
|
|
•
|
Send= Editor,Hold forwards a copy of the posting to the editor but differs from Send= Editor in that LISTSERV holds the posting for a period of time (usually 7 days) until the editor confirms the message with the "OK" mechanism (see below). Unconfirmed messages simply expire and are flushed by LISTSERV, so there is no need to formally disapprove a posting. This method of message confirmation is well-suited to lists where it is not often necessary to modify the text of a posting, and also is an excellent workaround if the editor’s mail program does not generate "Resent-" headers in forwarded mail.
|
A final method (called "self-moderation") exists for lists where subscribers should be allowed to post freely, but non-subscriber posts should always be sent to an editor for approval. To enable self-moderation, set
Send= Editor (or Send= Editor,Hold)
Editor= userid@host,(listname)
Ensure that "listname" is in parenthesis. Note that self-moderation will catch all posts from non-subscribers—including posts from subscribers who are posting from a different address. For instance, if the subscriber originally signed up as joe@foo.com but is posting from joe@unix1.foo.com, LISTSERV will treat his mail as non-subscriber mail. Self-moderation may require some slight changes in individual user subscriptions in order for it to work seamlessly. See also the
Default-Options= list header keyword description.
Depending on the setting of the Validate= list header keyword, certain LISTSERV commands have always required a password for execution. However, with a recognition that mail can be forged ("spoofed") by just about anyone on the Internet today, L-Soft introduced a "magic cookie" method of command validation that is considered much more secure than passwords.
In essence, the "magic cookie" method requires that the sender of the command must confirm his command via a reply containing only the text "OK". (This is actually simplistic; see below.) If mail is spoofed from the list owner’s user id, the command confirmation request will always be sent to the list owner’s user id, thus preventing the spoofer from confirming the command. Moreover, the "cookie" itself (an eight-digit hexidecimal number) is registered to the "From:" user id of the original command. A typical command confirmation request looks like this:
It is also possible to confirm multiple command confirmation requests with a single message (for instance, if you have
Send= Editor,Hold and have a number of requests to be responded to). This eliminates multiple "Message approved" mails from LISTSERV. However, make sure that you send the confirmations in a new mail message rather than replying to one of them. (See the "bracketed OK" syntax mentioned below.)
You can send the "OK" from any address, which helps when the address field of your mail gets changed somewhere along the line. For instance if you are logged into the web administration interface as joe@example.com and issue a command that requires mail confirmation, LISTSERV will send the request to joe@example.com (as expected). If your mail system expands joe@example.com to Joe_Doakes@mail.example.com, the "OK" will still succeed and Joe_Doakes@mail.example.com will get a message that says
> okConfirming:
> QUIET DELETE * jane@example.com
[reply sent to joe@EXAMPLE.COM]
OK BEGIN
command1
command2
...
command3
OK END
Note: In a "bracketed OK" the aggregate length of the data stream (that is, the total number of characters in the command lines falling between OK BEGIN and OK END) MUST be less than 32K characters. In practice you should use bracketed OKs for limited numbers of commands only, say no more than 10-12 at a time. In particular, if you have many ADD or DELETE commands to send, it is far more efficient (and strongly preferred) to use the bulk ADD and bulk DELETE syntaxes described in Section 15.17
Bulk Operations (ADD and DELETE).
(for instance, "OK CANCEL 8F2E8F4B"), and if the cookie is valid, LISTSERV will respond "Confirmation code 8F2E8F4B cancelled." If the cookie is not valid (e.g. has expired, has already been cancelled, or is simply incorrect), LISTSERV will send its standard message telling you in part that "The confirmation code 8F2E8F4B does not correspond to any pending command."
In addition to methods listed above for restricting service areas and the like, LISTSERV has a varied set of methods whereby "problem users" may be denied service on several levels.
List owners or LISTSERV maintainers may filter specific userids (or users matching a wildcard specification) on a list-by-list basis by using the
FILTER= list header keyword. For more information, see the
List Keyword Reference document.
LISTSERV maintainers may add specific or wildcarded userids to LISTSERV's built-in filter by using the
FILTER_ALSO= configuration file variable. Users matching this specification will be denied service to all LISTSERV services on your server.
The LISTSERV maintainer may selectively "serve out" specific userids with the SERVE command. This use of the SERVE command creates a "hard" serve-out which only a LISTSERV maintainer may override, as opposed to the "soft" serve-out that occurs when 51 consecutive bad commands are sent to LISTSERV which any user (other than the served-out user) can override. This function is particularly useful for temporary suspensions of service to certain userids, as it does not require modifying the site configuration file, but naturally it may be used to serve users out permanently. The SERVE command does not accept wildcards, so if you need to suspend service to a class of users rather than to a specific user, you should use the
FILTER_ALSO configuration file variable as described in Section 23.8.2
The "FILTER_ALSO" Configuration File Variable.
LISTSERV writes an entry for each served-out user to its PERMVARS FILE. (PERMVARS FILE is not a plain-text file; do not edit it by hand.) To serve a user out manually, the LISTSERV maintainer sends the command:
The password is required. Acceptable passwords are the list creation password (
CREATEPW), the system file modification password (
STOREPW), or your personal password set with the
PW ADD command.
Note: Prepending QUIET to the SERVE command suppresses notification to the user in question. If you are serving out an ID that is causing a mailing loop, you will probably want to use QUIET to avoid sending a fresh message to the looping ID.
Because the postmaster does receive notifications when a served-out user attempts to send mail to the server, the
SERVE command also has a
DROP sub-command that can be used to tell LISTSERV to "drop on the floor" all mail from that served-out address. For instance,
When a user is served out by the LISTSERV maintainer, assuming the QUIET modifier is not prepended to the
SERVE command, a message similar to the following is sent:
Date: Thu, 6 Dec 2001 09:45:40 -0500
From: "L-Soft list server at LISTSERV@LISTSERV.EXAMPLE.COM (1.8e)"
<LISTSERV@LISTSERV.EXAMPLE.COM>
Subject: Message ("Your access to LISTSERV has just been suspended...")
To: baduser@somehost.com
> serve listJOE@EXAMPLE.COM DROP 2003-08-20 15:51:20 by nathan@EXAMPLE.COM
FOOBAR@EXAMPLE.EDU HARD 2003-04-07 14:55:29 by
NATHAN@EXAMPLE.COM
BLAB@FOO.EXAMPLE.COM SOFT 2004-09-14 10:53:18
SPAMMER@SPAMDOMAIN.COM SPAM 2003-08-20 15:50:55
4 matching entries.
When a SOFT serve has no date associated with it (as it would if it happened prior to LISTSERV 14.3 or later), today's date is recorded and the record kept internally by LISTSERV is updated. New SOFT serves have their date recorded from the onset.
|
•
|
SINCE(date): show only entries from and including a specific date. Use parentheses if you want to supply the date in a multi-word format like SINCE(3 Jun 2006), otherwise something like SINCE 2006-01-01 (without the parentheses) is acceptable.
|
|
•
|
UNTIL(date): same as above for the other end of the range.
|
The old syntax ('SERVE LIST [options]') is still accepted for everything except the RESET option, which requires a wildcard specification (and requires the new syntax).
Most larger LISTSERV installations probably have thousands of SERVE entries that have accumulated over the years as administrators have battled spam. Only a fraction of the addresses so served off are likely to be in use today, but they continue to make SERVE LIST unmanageable, and continuing to maintain them comes at a resource cost. In addition, many spammer addresses were likely served out prior to the availability of the DROP option, which just causes more spam for the LISTSERV administrator to deal with.
While there is no absolute necessity to purge the list of served-off addresses, the new functionality at least provides the ability to "SERVE LIST SINCE" recent history, and to avoid having a list of thousands of addresses sent back when all that is desired is the list of those who were served off in the last week.
See the Advanced Topics Manual for LISTSERV for information on programming list exits and the POST_FILTER list exit point.
It is possible to hide part or all of a list header (except for the list title) from users who send the REVIEW command or who try to view the list's configuration via the CataList. The following syntax is used:
* My very own list*
* blah blah blah
*.HH ON
* This line is hidden
* This line is also hidden
*.HH OFF
* This line is not hidden
The sequence can be repeated as many times as required. GET will return the unedited header with the
.HH sequences,
REVIEW will replace hidden lines with a note saying that lines were hidden. You can't hide the fact that some lines were hidden because it would lead to people spending hours trying to figure out problems which only appear to be problems because some of the keywords are not visible. L-Soft will not field support inquiries with hidden headers; you must send the entire raw header (including the .HH lines) when requesting support.
LISTSERV includes a "Change-Log=" list header keyword which, when set to "
Yes", causes the server to log information about changes to individual subscriptions for a given list to a
listname.CHANGELOG file (
listname CHANGELG on VM). Changelogs also log postings to the list. Please see Section 19.6
Change Logs and the
List Keyword Reference document for more information on the "
Change-Log=" keyword.
